@redonkulus I gave it a try today. I just realized that there is another breaking change: since we are not using the old context anymore, we can't have in our API the feature of injecting other context values besides fluxible ones:

connectToStores

// before
function connectToStores(Component, stores, getStateFromStores, customContextTypes)

// after
function connectToStores(Component, stores, getStateFromStores)

provideContext

// before
function provideContext(Component, customContextTypes)

// after
function provideContext(Component)

Would it be a problem?

By the way, besides injecting react context values, provideContext was also using customContextTypes to extract values from the fluxible context and inject in the child context (perhaps a value added by a plugin). We could rewrite it in this way:

// before
function provideContext(Component, customContextTypes)

// after
function provideContext(Component, pluginsKeys)

provideContext(Component, ['plugin1', 'plugin2'])

What do you think? (was I clear enough?)

I think that makes sense as long as users can still add to the context. Otherwise, we would have to recommend an alternative method. @lingyan can you remember often we add custom context values, I know plugins do, seems like this would be a common thing.

I would recommend testing this in the doc site to see if any other issues come up.

Unrelated, but it would be good to migrate to import / export in these files too. This would help with tree shaking as well.

@redonkulus Another breaking change while updating fluxible-router: NavLink use to have a possibility to use a custom logger through contextTypes as well. I removed that so I could consume fluxible-context easily inside the class. Would that be fine?

I think that makes sense as long as users can still add to the context. Otherwise, we would have to recommend an alternative method. @lingyan can you remember often we add custom context values, I know plugins do, seems like this would be a common thing.

I would recommend testing this in the doc site to see if any other issues come up.

Unrelated, but it would be good to migrate to import / export in these files too. This would help with tree shaking as well.

I didn't get what makes sense. I see 3 possibilities here:

1. Remove customContextTypes support (users will have to come up with their own react context to provide fluxible plugin values);
2. Convert customContextTypes object to pluginsKeys to an array. (Still breaking change, but we keep the feature);
3. Keep as it is (no breaking changes, but it is unnecessary to get an object with prop-types);

For the commonjs issue, I've just create another PR (#664 )

@redonkulus I've added back the customContextTypes feature in provideContext. Now, one can pass an array of plugins keys to inject its content into the state provided by FluxibleProvider. It is still a breaking change but the migration should be simple (just extract the keys from customContextTypes into an array).

@pablopalacios Sounds good. Can you start a MIGRATATION.md doc in this branch to keep track of the breaking changes and what the code changes will be?

@redonkulus I've removed FluxibleConsumer and useFluxible from this PR since it is out of scope. So here you will find only the necessary steps to replace the obsolete react context. I created a initial document for the migration guide, but I did this in another PR (#665) so it doesn't block the code development.

By the way, would it be possible to rebase the 1.x-dev branch on top of master?

By the way, would it be possible to rebase the 1.x-dev branch on top of master?

@pablopalacios Ok I've rebased and pushed, please update your fork.

@redonkulus, @lingyan any comments here?

Sorry, I will get this merged and released today.